Expere Engine and Tools Change Log Entries
Expere Engine Release: 2017.1External release date is TBD. Expere Engine build number is: 2017.1.0.4369
| SignerID issue resolved |
|---|
|
Issue: It was reported that SignerID was being returned with no string value present, where in pervious versions they were either given a string or 'null' value. This caused corresponding breaking changes to related processes. |
Solution: This issue has been resolved; SignerID now returns either a string or 'null' value in the Expere response file. |
| Implementation Notes: This feature requires a 2017.1 Expere Engine update. |
| Previously failing transactions now generate normally |
|---|
|
| Issue: An issue was identified that caused transactions to fail when using eSignature functionality. It was determined that a missing element existed in the base functionality. |
| Solution: This issue has been resolved. |
| Implementation Notes: This defect correction requires a 2017.1 Expere Engine update. |
| Expere Engine change log updated with 2017.1 schema information |
|---|
|
| Summary: Our Expere Engine change now includes information regarding any schema additions and updates, allowing our users to identify schema changes between releases. We have created a new Schema Changes section on the Change Log and Important Notifications page for each release. |
| Implementation Notes: This new feature is available in the 2017.1 release. |
| Expere now updated to support latest versions of Microsoft Windows and SQL |
|---|
|
| Summary: The Expere Engine has been tested to validate that it functions properly with Windows Server 2016 and SQL 2016. |
| Implementation Notes: This feature requires a 2017.1 Expere Engine update. For more information, consult the Expere System Requirements guide: Windows Environment Software Requirements. |
| Package functionality added to Select, SelectAndGenerate, and Generate API's |
|---|
|
Summary: We have enhanced the Select, SelectAndGenerate, and Generate API's to accept custom packages through a new <InlinePackage/> parameter within each of these API's. This allows users to create or modify one or multiple custom packages for a particular line of business or precedence unit by selecting documents from one or more package or autoselection rules. |
Implementation Notes: Consider the following:
|
| eSignature Field Order enhancement |
|---|
|
Summary: We modified the method for applying enumerated values to the <eSignature/> fields so that the sequencing method always assigns the highest value in the sequence of each signer to their respective <Type>Signature</Type> fields, hence making the Signature field the last field in the order. |
Technical Notes: Here is an example response: |
Implementation Notes: This enhancement requires picking up the Expere Engine 2017.1 release. and setting the <eSignatureWKES/> option to "true." |
| WKES Sign Date Naming Convention |
|---|
|
| Summary: The WKES Sign Date fillable field naming convention has been updated from WKES_date to WKES_signdate. |
| Implementation Notes:No user action is required. |
| eSignature Enhancements |
|---|
|
| Issue: We have updated the field name elements for the eSignature and eSignatureDate within the PDF and ExpereResponse file as part of the SignaturePointSet element. The eSignature field name has been updated to no longer include the borrower name, additionally, the eSignatureDate field name for Static content has been updated to be consistent with Dynamic content. |
| Solution: The specific changes to the eSignature and eSignatureDate field names are captured below. Before: eSignature Field Name: SIG_Borrower_1_1_true_1_BobbyBorrower_BW1Name.eSig eSignatureDate Field Name: BW1Name.eSig.eSigDate After: eSignature Field Name: SIG_Borrower-1_1_true_1_BW1Name.eSig eSignatureDate Field Name: SIG_Borrower_1_1_true_1_BW1Name.eSig.eSigDate |
| Implementation Notes:No user action is required. |
| EnableEsignatureManifest Added to BSI.Properties |
|---|
|
| Summary: As a means to enable or disable the esignature manifest file we have added a flag, EnableEsignatureManifest, to BSI.Properties. With the default of FALSE, Expere does not look for the esigmanifest file as part of the content. When set to TRUE, the esigmanifest file is expected to be in the content repository. |
| Implementation Notes:No user action is required. |
| Version Number Added to Schemas |
|---|
|
Summary: We have included a version number in all Expere request and response schemas, such as ApiTypes.xsd and PackageAndDocSet.xsd; this will help users identify the version of schema with which they are working.Note: The schema version number is synonymous with the Expere Engine version number.
|
Technical notes: A sample version number resembles the following (see version= below): |
| Implementation Notes: No user action is required. |
| New ApplyPoliciesAndReturnTransaction API introduced |
|---|
|
Summary: The ApplyPoliciesAndReturnTransaction API has been implemented to update the provided transaction with the provided Product information. This allows users to pass the updated returned transaction (which includes the Product information) into our DocViewer application, as well as the ability to use Select, SelectAndGenerate, or Generate API's to generate documents with product data. |
| Implementation Notes: See ApplyPoliciesAndReturnTransaction for detailed information on using this new API. |
| Ancillary Barcodes Not Rendering on Dynamic Documents |
|---|
|
| Issue: Ancillary barcodes contained in a request would not render on dynamic documents. |
| Solution: This did not impact static documents. This has been repaired so requests with ancillary barcodes will render as expected on dynamic documents. |
| Implementation Notes: No user action is required. |
| Expere Engine: Pinyon Script added to JetFonts.xml |
|---|
|
Summary: We have added Pinyon Font to the jetfonts.xml file within our Expere Engine. This will allow users to generate a static document with a script font. |
| Implementation Notes: No user action is required. |
| Text string area message enhanced |
|---|
|
Summary: Previously if a <Text/> element's text string contained more characters than what was allowed, an error message was logged. We have updated the logging level for this message to be WARN instead of ERROR. |
| Implementation Notes: No user action is required. |
| Logging levels updated |
|---|
|
| Summary: Previously, all exceptions that appeared in our log files were reported as errors. This did not reflect the nature nor severity of the exception being logged. |
Technical Notes: We have modified our level of logging to consist of the following:
|
| Implementation Notes: No user action is required. |